January-February 201 3 



Healthcare Analytics in Navy Medicine 

Perspectives and Methods for Decision-Making 


FOCUS ON DATA PRIVACY 

Ensuring Privacy Protection 
Linda S. Thomas, J.D., M.A. 

With richer data sources provided by electronic health records and centralized data systems, researchers can increasingly 
perform more sophisticated analyses, which yield critical insight and knowledge. As most of the data are personally 
identifiable information (PII) and/or protected health Information (PHI), the DoD(HA)/TMA and other providers have to 
walk a fine line between ensuring that patient information remains secure and creating processes through which health 
researchers can efficiently gain access to the necessary data. 


Ours is a time of tremendous opportunity. The econom- 
ics of digitizing records, recent legal requirements, and 
ever-greater data sharing have converged to generate 
huge databases that are rich data sources for sophisti- 
cated analyses. Within DoD alone, more than 9.5 million 
beneficiaries are covered by TRICARE. The huge asso- 
ciated databases enable research that demonstrates 
health trends in the U.S. population as a whole, and they 
permit examination of relatively rare occurrences or 
encounters with sufficient frequency to yield meaning- 
ful conclusions. Not only is there now the capability of 
such analytics, there is also a need and a push for their 
widespread use to improve care while reducing cost. 
The utility of good healthcare analysis applies not only 
to vital studies focused on clinical care, but also applies 
to healthcare business process or financial manage- 
ment issues, including the enrollment process, claims 
management, and routine communications. These data 
sets provide vast potential for well-formulated analyt- 
ical work to provide new insights as the the basis for 
creative solutions and refined best practices. There will 
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be synergies among many of these uses, resulting in new 
breakthroughs in care and practice. Thousands of such 
efforts can cumulatively establish improved techniques, 
better targeted clinical interventions, and fewer business 
process errors, potentially improving healthcare and 
managing its costs. 

Legal Requirements for Healthcare Privacy 

Against this backdrop of increasing demand for data to 
perform deeper analytics, it is important to remember that 
almost all of the data come from sources holding PII and 
PHI. PII is any information that can be used to identify, 
contact, or locate an individual, either alone or combined 
with other easily accessible sources. PHI, a form of PII, 
is individually identifiable health information. While 
the Privacy Act of 1974 regulates the collection of 
personal information by government agencies, HIPAA 
(as amended by HITECH) and the associated U.S. 
Health and Human Services regulations govern health- 
care privacy in the U.S. and apply to both the private 
sector and Government. 1,2 Specifically, HIPAA’s Privacy 
Rule legislates the use and disclosure of PHI and prohib- 
its disclosure unless mandated or permitted by HIPAA. 
However, HIPAA applies a balanced approach, permit- 
ting operational quality assurance, data sharing, and 
also research, so long as proper privacy protections and 
procedures are followed. These permitted activities may 
employ analysis. At DoD, these provisions are imple- 
mented by DoD 6025. 18-R. 

Although these categories of activity — quality assurance, 
access or capture of data for various other purposes, and 


1 Health Insurance Portability and Accountability Act of 1996, Public 
Law 104-191. 

2 Health Information and Technology for Economic and Clinical Health 
Act, 42 U.S.C. §§ 300jj et seq; §§ 17901 et seq. 




research — are provided for under HIPAA in appropriate 
cases, such activities are subject to rigorous additional 
requirements designed to safeguard the privacy of the 
individuals to whom the information is related. Quality 
assurance is guided by 10 U.S. C. § 1102, which mandates 
that records associated with quality assurance are kept 
confidential and privileged, with certain exceptions when 
data are needed to perform official duties. 3 

Requirements for Data Sharing 

Additionally, any proposed access to our beneficiaries’ 
health data from a non-DOD(HA)/TMA source must 
meet Data Sharing Agreement (DSA) requirements. 4 5 6 If 
a contractor is seeking the data (whether on its own or 
on behalf of a Federal or other governmental agency), a 
Business Associate Agreement (BAA) is also required. If 
the data will be housed on a non-DoD network, a System 
Security Verification (SSV) form must also be submitted 
and evaluated to ensure that the platform has adequate 
security to safeguard the data. Requests for access to our 
data that are not for research account for approximately 
70 percent of such requests and occur for a wide vari- 
ety of reasons, including advisory services, business case 
analysis, forecasting costs, program evaluation, and stra- 
tegic healthcare planning. 

Moreover, proposed research on human beings, which 
can involve either interacting with a person or viewing his 
or her information in a database, has even more stringent 
requirements that must be met before being approved. 
Research projects must be evaluated by an Institutional 
Review Board (IRB), which ensures compliance with the 
Common Rule. 5,6 In addition, at DoD, since TRICARE 
is a Covered Entity under HIPAA, we must meet added 
requirements including Secondary Review of the primary 
IRB results and HIPAA compliance, both of which occur 
under the oversight of the TRICARE Human Research 
Protection Program (HRPP). 7 Requestors should note that 


3 10 U.S.C. Armed Forces, §1102: Confidentiality of medical quality as- 
surance records; qualified immunity for participants. Implemented by DoDI 
6025.13, Medical Quality Assurance (MQA) and Clinical Quality Manage- 
ment in the Military Health System (MHS), February 17, 2011. 

4 TMA Data Sharing templates generally implement the provisions of 
45 CFR Subtitle A § 164.514. See also http://www.tricare.mil/tma/privacv/ 
DataSharingAgreements.aspx for additional information. 

5 Research is “a systematic investigation, including research development, 
testing and evaluation, designed to develop or contribute to generalizable 
knowledge.” 32 CFR 219.102(d). 

6 The Common Rule, widely adopted among Federal researching agencies 
including DoD, is a set of ethical principles designed to protect research 
subjects through such requirements as minimizing harm. See 32 CFR 219, 
and DoDI 3216.02. 

7 See http : / / www. tricare .mil/ tma/pri vacv/hrpp for additional information. 


the evaluation of proposed data access is greatly stream- 
lined for both research and non-research requests when 
the data to be accessed is truly de-identified (i.e., no abil- 
ity to associate the record with any particular individual). 8 

Balancing Privacy with Appropriate Data Sharing 

In sum, HIPAA balances privacy protections with 
appropriate pathways for disclosing health information 
appropriately for recognized purposes. It specifies many 
considerations for safeguarding PII/PHI, with some vari- 
ation according to the circumstances (i.e. whether the 
proposed study conducts research or not). Though such 
requirements may initially slow access, they are key to 
the success of research and analysis because it is in that 
safety of privacy protection that beneficial analytic work 
can be performed. N ote that such provisions for safeguard- 
ing privacy are only effective and real when the HIPAA 
provisions are properly incorporated into the oversight 
program by use of correct language in agreements, as 
well as correct policies, procedures, and follow-through. 
A robust oversight program recognizes that the tension 
between privacy protection and appropriate data sharing 
is not so much indicative of a conflict as it is a caution, 
signifying the need to build the oversight program prop- 
erly from the ground up and assiduously adhering to 
the needed provisions. This is absolutely worth doing 
because the benefits from facilitating data sharing and 
research yield life-giving insight and knowledge and lead 
to greater healthcare and well-being. Such outcomes are 
mighty indeed. 

Linda Thomas is the director of the TRICARE Manage- 
ment Activity (TMA) Privacy and Civil Liberties Office. 

SKILLS AND METHODS 

-PRACTICAL IMPLICATIONS OF USING PHI/PII 

All users of MHS data have the responsibility of protect- 
ing beneficiaries and themselves against unauthorized 
uses or releases of data. Patient privacy is critically impor- 
tant. There are many laws and regulations that describe 
an organization’s responsibilities with respect to data 
handling. This article focuses on protections afforded by 
HIPAA and the Privacy Act. 

When analysts come into contact with PHI and/or PII, 


8 De-identification can occur either through elimination of 18 specified 
data elements, or by the removal of sufficient data elements that a statistician 
would determine the risk of possible reconstruction as identifiable health in- 
formation was very small. 45 CFR Subtitle A § 164.514. 
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there are responsibilities that must be fulfilled. First, the 
use must be an approved use of identifiable information, 
such as healthcare planning, management or opera- 
tions. The type of approvals needed varies, depending on 
the intended use and whether the user is a government 
employee or contractor. Users with access to PHI/PII 
must only use the data for the purpose in which the user 
was granted access. Second, if PHI/PII is going to be 
stored in a database, that database must be covered by a 
system of records notice (SORN). SORNs are published 
in the Federal Register and inform the public about poten- 
tial uses of data. 9 Third, the user’s workstation must be 
deemed secure by the TMA or Service Privacy Office. 
Finally, the user must document all uses of PHI/PII. 

HIPAA covers the use of PHI, and the Privacy Act covers 
the use of PII. Some specific data elements in Military 
Health System (MHS) data sources that are considered 
PHI and/or PII include: 

• Beneficiary name 

• Free text data fields 

• Locations related to a person (geographic subdivisions 
below the level of state - specifically, subdivisions of 
less than 20,000 individuals, such as catchment area 
and PRISM area) 

• Individual dates related to a person (such as dates of 
birth or dates of service) 

• Age (any age over 90) 

• Contact information (such as email address, phone 
numbers, and fax numbers, address already prohibited 
due to geography restriction noted earlier) 

• Social Security Numbers (SSN) 

• Medical record numbers (such as sponsor SSN and 
family member prefix) 

• Health plan beneficiary numbers (such as DEERS 
person ID) 

• Any other unique identifying number, characteristic, or 
code (such as a “catch all” to enable protection of other, 
perhaps unique data such as rank) 

De-identification 

Because it can be difficult to comply with all of the rules 
for using PHI/PII when using data locally, many analysts 
either keep data on a government-secured SORN (such as 


9 More information about SORNs can be obtained at http://www.opm.gov/ 
information-management/privacy-policy/privacy-references/sornguide.pdf. 


the MHS Data Repository), or they de-identify data prior 
to downloading locally. De-identification of data involves 
much more than simply encrypting person identifiers or 
removing items such as name. De-identification must also 
address whether data elements identified under HIPAA 
or the Privacy Act are included, whether covered data 
elements are needed, whether the encryption methodol- 
ogies used are secure, whether small sizes would make 
identification possible, and whether the user has access 
to any data that would enable re-identification. The HHS 
Office for Civil Rights (OCR) released new guidance on 
methods for de-identifying PHI in accordance with the 
HIPAA Privacy Rule in November of 2012. Mandated 
under section 13424(c) of the Health Information Tech- 
nology Economic and Clinical Health (HITECH) Act, 
this guidance provides useful clarifications, details and 
best practices on de-identification (see “New Knowl- 
edge” section for additional details on these guidelines). 

Encryption 

There are two types of encryption approaches used to 
de-identify and protect PHI/PII data: field-level encryp- 
tion and file-level encryption. When handling PHI and PII 
data, both field-level encryption and file-level encryption 
should be used. 

Field-level encryption is defined as encryption of the 
individual data fields within a file. For example, a random 
record ID might be generated for each person in a study, 
rather than using the DEERS Person ID, otherwise known 
as EDIPN. A complete de-identification description of 
field-level encryption must include specific language 
that describes use of an algorithm to encrypt the data 
fields. Simply re-ordering an identifier, such as SSN or 
EDIPN, is insufficient. In addition, a proper de-identifi- 
cation description must clearly define exactly what fields 
are being encrypted, such as SSN, EDIPN, dates, age, etc. 

File-level encryption is typically used when data are distrib- 
uted to other organizations. File-level encryption is defined 
as using 256-bit software, such as WINZIP or TrueCrypt, 
to encrypt a file. This puts a protective shell around the data 
during transport, but this method does nothing to protect 
the data once the file is decrypted upon opening 

Small cell sizes 

Small cell sizes are of particular concern in that a 
person’s identity can often be deduced by using particu- 
lar combinations of data elements to aggregate or report 
data. Combinations of geographic subdivisions based on 
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patient residence, treatment locations, specific patient 
characteristics (e.g., race and age), and rare diagnoses 
and procedures can be particularly problematic. The 
OCR de-identification guidelines recognize that small 
cell sizes can lead to identification of patients; however, 
a specific number to define small cell size is not clarified. 
Many organizations require analysts to redact or roll-up 
anything with cell sizes less than 30, but this is not always 
the case. 

Re-identification 

Re-identification is when a user has access to more than 
one data source that can be tied together to deduce a bene- 
ficiary’s identity. For example, consider a CHCS user 
(identifiable PF1I data) accessing the M2 restricted option 
(PFII, but with only encrypted direct person identifiers 
accessible). This user would be approved for PFII access 
to direct care information at their local MTF, but not for 
worldwide direct and purchased care access. However, by 
tying the CHCS data to the M2 data, the user would be 
able to re-identify many of the patients in the M2 data. 
Thus, a user’s data access to multiple source systems must 
always be considered before determining whether a data- 
set is truly de-identified. 

Other Sensitive Data 

There are additional concerns specific to the use of MHS 
data. For example, rank and military unit are both poten- 
tially identifiable elements not directly specified in HIPAA 
or the Privacy Act. Also, some data elements are consid- 
ered procurement sensitive or proprietary (e.g., ingredient 
cost in the pharmacy data) and must be handled as such. 
Other data elements have restrictions related to whether 
or not it can be released and how it can be used (e.g., data 
elements specifying cause of death and specific deploy- 
ment information). 

Summary 

When using health information, it is best for users to try 
to avoid the use of PHI or PII. This is not always entirely 
possible and uses of PHI/PII are allowed with the right 
permissions and circumstances. However, users must 
take caution and protect the information when it is used. 
Disclosures of PHI and PII can have devastating conse- 
quences to beneficiaries. Treat access to PHI/PII as if it 
were data about you! 


DATA AND INFORMATION SYSTEMS 

-THE DSA PROCESS EXPLAINED 

The purpose of this article is to describe: (1) the Data 
Sharing Agreements (DSA), the Data Sharing Agree- 
ment Application (DSAA) and Supplemental DSA-related 
templates required when TMA-owned or managed data 
(TMA data) are requested; (2) key supporting elements 
that may also be required; (3) specific Navy Medicine DSA 
requirements for Navy Medicine-owned or managed data . 

TMA Data Sharing Agreements (DSA) 

When a contractor or member of a non-government entity 
requests access to TMA data, including de-identified 
data, a DSA is required. The DSA serves as an agreement 
between a recipient of data and the Privacy Office. The 
DSA documents the agreed upon responsibilities of the 
government sponsor and of the recipient, outlines permit- 
ted uses and disclosures, documents compliance with 
DoD privacy and security regulations, and identifies the 
data that is required to meet a specified need. The DSA 
is executed when signed by a Government Sponsor, the 
Data Recipient, and the TMA Privacy Office. 

The DSAA is the application used to initiate a request 
for access to TMA data. 10 A completed DSAA contains 
the information to enable the Privacy Office to determine 
whether the data use is in compliance with applicable 
guidance. Necessary information includes: 

• Contract information 

• Data specifications including data systems / files / 
elements 

• Method of access (login or extraction) 

• Description of data use, storage, and disclosure 

• System security information 

Regarding signatures, before submitting a DSAA, the 
Applicant and Sponsor must initial the application to 
certify that the information provided is accurate. The 
Applicant is the individual (normally from the orga- 
nization contracted to support the project) who will 
provide primary oversight and responsibility for the 
handling of the requested data. The Government Sponsor 
is the government point of contact within TMA, or the 


10 Requestors of data (TMA- or Navy Medicine-owned and managed) for 
Navy purposes should route all DSAAs through the BUMED IT Privacy and 
Security Division (BUMED-62). Additional details and contact information 
appear later in this article. 
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respective Armed Service, having overall responsibilities 
regarding the data use for the project funded by the refer- 
enced contract, grant, project, or Cooperative Research 
and Development Agreement (CRADA). 

In addition to information provided on the DSAA, the 
submission of a Data Request Template (DRT) with the 
DSAA is also required. 11 In compliance with HIPAA’s 
“minimum necessary rule,” the Privacy Office created the 
following three DRTs to prompt Applicants to specifically 
list the requested data elements and or data categories: 

• MHS Data Repository (MDR) DRT — Required for 
MDR extractions only 

• General DRT — Required for extractions of TMA 
systems other than MDR 

• Access DRT — Required for any TMA system to which 
direct login access will be used (e.g., M2) 

After the DSAA packet is approved, the DSA will be sent 
to the Recipient (previously referred to as the Applicant on 
the DSAA) and Sponsor for signature. After the Recipient 
and Sponsor sign and return the DSA, the Privacy Office 
will provide final signature. The executed DSA, incorpo- 
rating the approved DSAA, will be sent to the Recipient 
and Sponsor as the final step of an executed DSA. 

Key Supporting Elements for a DSA Approval 

Please be aware that, in addition to submitting the DSAA 
and the DRTs, the Privacy Office requires additional 
supporting elements also be submitted in appropriate 
cases. These supporting elements include: 

• Specific Contract Language — The Privacy Office will 
not approve a DSA until specific language requirements 
are met in contracts supporting the Applicant’s work. 
The specific contract language required can be found at 
http://www.tricare.mil/tma/privacv/contractlanguage. 
aspx . Contracts require this specific language when: 

o The work involves the use of personal information 
(PII/PHI language) 

o The contract is awarded in support of a function or 
activity involving the use of PHI (Business Associate 
Agreement (BAA) language) 

o The contractor utilizes PHI in any form (HIPAA 
language) 


o Records are collected, maintained and retrieved 
by personal identifier (system of records (SORN) 
language) 

o A system or project collects, maintains, or dissemi- 
nates PII from or about members of the public totaling 
at least ten individuals (PIA language) 

• System of Records Notice (SORN) — If the requested 
data will be stored as a system of records, a SORN is 
required prior to the approval of a DSA. Published in 
the Federal Register, a SORN provides public notice that 
data is collected and stored under the control of a federal 
agency. A SORN describes: how the data are retrieved 
by personal identifier (e.g., name, SSN, date of birth), 
the purpose of the data collection (e.g., any internal uses 
of the data), and the “routine uses” of the data (e.g., any 
time disclosures external to the DoD are made). 

• Authority to Operate (ATO) or System Security Veri- 
fication (SSV) — To confirm that the requested data are 
protected using appropriate procedural, administrative, 
technical and physical safeguards, the Privacy Office 
requires confirmation of a current Authority to Oper- 
ate (ATO) or an Interim Authority to Operate (IATO). A 
current ATO or IATO is required if data are accessed, used 
or stored on a DoD network or system or Government- 
furnished equipment (GFE). If a data Applicant does not 
have an ATO, the Privacy Office requires submission and 
approval of a System Security Verification (SSV). SSVs 
are necessary if data will be accessed, used or stored on a 
non-DoD network or a non-DoD computer (i.e., contrac- 
tor-owned network or system). 

• Research Requests — If a data request is for research 
purposes involving human subjects, research protocol 
approval by a constituted Institutional Review Board 
(IRB) is required prior to DSA approval. In addition, the 
research protocol must be reviewed by the OASD(HA)/ 
TMA Human Research Protection Official (HRPO). All 
research review requirements and submission instruc- 
tions can be found on TMA Human Research Protection 
Program website at http://www.tricare.mil/tma/privacv/ 
hrpp/default.aspx . 

All DSAA forms, DRTs, and additional supporting docu- 
ments corresponding with TMA DSAs can be found on 
the Privacy Office website at h Up :// ww w. tr i care . m i l/tm a/ 
privacy/ default, aspx . For further information regarding 
TMA DSA process, please email DSA.mail@ tma.osd.mil . 


1 1 If the requested data elements are attached to the DSAA using a docu- 
ment other than the DRT, it will be reviewed in lieu of the DRT. 
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Navy Medicine Data Sharing Agreements 

According to Navy Medicine Memorandum 6010, SER 
M6/12UM6172, Navy Medicine has adopted the DSA 
requirements and templates established by the TMA 
Privacy Office. The policy memorandum, dated Novem- 
ber 13th, 2012, establishes Navy Medicine policy and 
responsibilities for DSAs. This implementation standard- 
ized processes to ensure consistent practices between 
Navy Medicine and TMA. It also reduced the request- 
er’s need to complete redundant forms, the potential 
for re-work of submissions, and the amount of time for 
review and approval. This standardization is especially 
helpful for requests involving data from both TMA- and 
Navy Medicine-owned and managed systems. 

Individuals who need access to MHS sensitive data for 
Navy purposes will complete the TMA Privacy Office 
DSAA template and then route the request and any ques- 
tions to the BUMED Information Technology (IT) Privacy 
and Security Division (BUMED-M62). Requests can be 
emailed to DUA.BUMED@med.navy.mil . BUMED 
M-62 approves Navy Medicine DSAs or endorses 
the DSAA for approval to TMA for data they own and 
manage. Guidance on DSA requirements is available at 
the M-62 portal at https://es.med.navv.mil/bumed/m6/ 
m62/Pages/Program.aspx . 

For further information regarding Navy Medicine 
DSAs, please contact Barbara Flazzard (BUMED 
M62 - IM/IT, Privacy and Security Navy Medicine) at 
barbara.hazzard.ctr@med.navy.mil . 

NEW KNOWLEDGE 

-THE DE-IDENTIFICATION OF DATA 

This article provides an overview of the new U.S. Depart- 
ment of Elealth and Eluman Services (DEIEIS) Office of 
Civil Rights (OCR) guide for the de-identification of data. 

The F1IPAA Privacy Rule regulates the use and disclo- 
sure of PFII. PF1I is any information that includes health 
status, provision of health care, or payment for health care 
that can be linked to an individual either through unique 
person identifiers (such as name or SSN), small sample 
size, or specified geographic area. Because E1IPAA recog- 
nizes the value of administrative and clinical information 
that is now more available with electronic health records, 
it permits de-identification of health data for the use of 
“secondary purposes” such as comparative effectiveness 
studies, policy assessment, and health services research. 


De-identification is the process by which identifiers are 
removed from health information in an effort to diminish 
privacy risks to individuals. 

Although the EIIPAA Privacy Rule makes provisions for 
data de-identification for permitted secondary purposes, 
it does not specify standards for how de-identification 
should be done. Recently, however, the DEIF1S OCR 
released guidelines clarifying methods that can be used 
to satisfy the EIIPAA Privacy Rule’s standard, and these 
guidelines can be found at http://www.hhs.gov/ocr/ 
privacy/hipaa/understanding/coveredentities/De-identifi- 
cation/guidance.html#protected . 

As shown in Figure 1, the methods OCR clarified as 
options for de-identifying PHI include: 

• Expert Determination — Under the Expert Deter- 
mination method, a covered entity (e.g. health plan, 
health organization) or business associate must use an 
expert with appropriate knowledge of and experience 
with generally accepted statistical and scientific prin- 
ciples that properly de-identify the health information 
in question. This expert must certify that the statistical 
and/or scientific methods used render the information 
not individually identifiable, thus mitigating risk of 
re-identification to “very small.” This guideline does 
not list any specific criteria or a professional degree that 
the expert must possess, nor does it try to quantify the 
level of risk that quantifies “very small.” 

• Safe Harbor — Under the Safe Harbor method, numer- 
ous types and categories of information are eliminated 
from the health information in question. These iden- 
tifiers include all unique identifying numbers (e.g. 
certificate, license, medical record, health plan bene- 
ficiary, device, serial, and patient numbers), name, 
contact information (e.g. telephone, email, fax, URLs, 
IP address), full face photographs, as well as dates more 
specific than a year or geographic subdivisions that are 
smaller than 3 digit ZIP Codes unless they contain less 
than 20,000 individuals. Data files that contain “free 
text” or appear in “free text form” may also contain 
PHI and should be included in this screening process. 
In fact, this guideline specifies that de-identification has 
not been achieved if an organization has knowledge of 
remaining non-specified information that can be used 
alone, or in combination with other reasonably avail- 
able information, to identify an individual. 
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Health information that has undergone de-identification 
through either Expert Determination or Safe Harbor is no 
longer protected by the Privacy Rule, as it does no longer 
meets the definition of PHI. While de-identification does 
result in loss of information and can diminish the useful- 
ness of the data, the process still provides organizations 
with valuable data for analyses and research. 

Figure 1. OCR Guidelines for the De-Identification of PHI 
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WHAT’S COMING UP 

Change your bookmarks! 

The MDR and M2 data dictionaries, along with the 
functional specifications and the interface control docu- 
ments (ICDs), have been moved to a new Defense Health 
Cost Assessment and Program Evaluation (DHCAPE) 
website at http://tricare.mil/tma/dhcape/data/fs.aspx . All 
the documents are now Section 508 compliant, meaning 
they are accessible by those with physical disabilities. 
Links pointing to the old website should be automatically 
re-directed to the new website, but all M2 and MDR users 
should update their bookmarks to ensure reference to the 
latest documentation. 

Defense Connect Online (DCO) Training Opportunities 

The TMA-sponsored WISDOM curriculum is being 
extended through use of monthly DCO sessions for the 
M2 community. Each of the webinars will be conducted 


at 9 a.m. EST and again at 5 p.m. EST, usually on every 
last Wednesday of the month. 

The following topics will be covered in the upcoming 
months: 

• UDOs and Local Variables - May 29, 2013 

• Prospective Payment System (PPS) - June 26, 2013 

• Vitals Data / Information in M2 - July 31, 2013 

• RVUs in M2 - August 28, 2013 

• Indirect and Direct Population Adjustments - 
September 25, 2013 

Please check the WISDOM webpage (http://tricare.mil/ 
tma/dhcape/data/wisdom.aspx) for updates regarding 
DCO topics and times, and also monitor your e-mail 
for M2 blasters with DCO session announcements. For 
recordings or information on past DCO sessions, go 
to M2/Infoview under Public Folders/M2/ TMA-HA/ 
Courses/WISDOM/WISDOM DCO Refreshers. 

BUMED PA&E is also sponsoring an upcoming series 
of DCO sessions on topics related to the evaluation of 
health systems. The specific session topics and dates will 
be announced in the next issue of Healthcare Analytics in 
Navy Medicine. 

TIPS AND TRICKS 

-HIPAA LOG PRACTICES 

HIPAA requires the government to be able to identify 
every individual who has used a person’s health data. To 
implement HIPAA guidelines in your office, a “chain of 
custody” should be documented in a HIPAA Log. This 
section describes best practices for creating and maintain- 
ing documentation to meet these requirements. 

All users of PHI/PII must create a HIPAA Log when 
they take custody of information. Taking custody means 
taking the data off of a source data system or instruct- 
ing someone to do so on your behalf. Whenever you are 
using MHS data systems that contain PHI/PII, you must 
be careful that you know when you are retrieving PHI/ 
PII. Not all reports from these systems are PHI/PII, but 
since users have ad hoc access, they have the ability to 
retrieve it. As a result, users are responsible for knowing 
the difference between PHI/PII and non-PHI/PII. 

HIPAA Logs are commonly used for tracking, and “chain 
of custody” information contained in these logs is usually 
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documented in a spreadsheet. In offices with multiple users 
of data, a consolidated master HIPAA Log is preferred to 
ensure that managers are cognizant of the use of PHI/PII. 
The master log should include all releases/uses of PHI/PII 
for the entire team of data analysts and researchers. The 
HIPAA Log serves as documentation of why and when 
data were used and how the data were disposed of. All 
logs should include the following: User Name, Company 
Name, Project Name, Task Number, Description of Data 
(including file names, file location, and data elements), 
Date Used, Disposition of Data (i.e. deleted, sent to some- 
one), Recipient (if applicable), Authority to Release (i.e. 
DUA number, role of person receiving data), and Method 
of Delivery. Table 1 is an example of a HIPAA Log that 
contains adequate information about the chain of custody 
of PHI/PII. 

In offices that use a master log, analysts should submit 
their individual logs to an Information Assurance Manager 
for monthly compilation. Keeping a consolidated log is a 
requirement of HIPAA and the various Privacy Offices. If 
you use PHI/PII very infrequently, instead of keeping an 
individual HIPAA log, report your usage to the Information 
Assurance Manager on an ad hoc basis. However, never 
send the PHI/PII data through email to the Information 
Assurance Manager; simply state that you have received 
PHI/PII and will be logging it that particular month. 


Please note that for the MDR, DHSS keeps a record of 
every program run so there is an expectation of what 
should be found in each analyst’s individual HIPAA Log. 
In addition to the HIPAA Log, if you are an MDR user, 
MDR internal logs should also be saved to represent each 
use. The regular maintenance of HIPAA Logs is critical 
because the U.S. Department of Health & Human Services 
(HHS) Office for Civil Rights (OCR) has the authority to 
inspect all health organizations in the United States for 
compliance with HIPAA and the Privacy Act. OCR is 
doing audits now and leveraging stiff fines on violators. 
All companies and divisions of the government should 
be on alert at all times and prepared with an up-to-date 
HIPAA Log, due to the possibility of an audit at any time. 

KNOWLEDGE SOURCES 

—A PERSPECTIVE ON GENERAL SCIENCE PERIODICALS 

The following review presents exposure to general 
science serial publications that contain articles useful for 
general professional growth and knowledge attainment. 

In the September-October 2012 issue of Healthcare 
Analytics in Navy Medicine, readers were presented a 
case for the value of general science periodicals as routine 
reading for analysts. One such recommended publica- 
tion is New Scientist, an international weekly periodical 


Table 1. Example HIPAA Log 


Date 

Company 

Data Extraction 
Performed by 

Task 

Order 

Project Name 

External Client/ 
POC 

File Received 
from External 
Source 

File Sent to 
External Agency 

Date 

Delivered 
to External 
Agency 

DUA# 

5/5/2010 

ABC, Inc. 

Sue Smith 

3001-008 

OCONUS 

Beneficiary Survey 

Marshall 
(sent to Tolbert) 

N/A 

c:/work/survey/ 
oconus.samples. 
aprl 1.txt, oconus. 
samples. mayl 1.txt 

5/5/2010 

#09-585 

5/11/2011 

ABC, Inc. 

Sue Smith 

2003-003 

TDP Survey 

Marshall 
(sent to Tolbert) 

N/A 

c:/work/survey/ 
tdp.samples.febl 1 . 
to.aprl 1.txt 

5/11/2011 

#09-585 




Node, Program 
Location & Name 

Source Data File 
Location & Name 

Hard Drive File 
Location & Filename 

PHI/PII 

Info 

Date Came in 
Contact w/ File 
(or Date 

downloaded from 
Data Source) 

Date of File 
Destruction 

Destruction 
Witnessed by 

Comments/Notes 

MDR: /hpae2/abcinc/ 
survey/aprl 1/ 
oconus.sas & 

/mayl 1/oconus.sas 

DEERS/CHCS 

phone 

C:/work/Survey/ 
oconus.samples. 
aprl 1.txt & oconus. 
samples.mayl 1.txt 

Name, 

phone 

5/5/2010 

5/5/2010 

John Doe 

Monthly OCONUS 
beneficiary survey 
sample 

(SFTP to Zogby) 

MDR: /hpae2/abcinc/ 
survey/mayl 1/tdp.sas 

FY10-11TDP, 

DEERS/CHCS 

phone 

C:/work/Survey/ tdp. 
samples.febl l.to. 
aprl 1.txt 

Name, 

DOB, 

phone 

5/11/2011 

5/11/2011 

John Doe 

Quarterly TDP survey 
sample 

(SFTP to Zogby) 
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published in the United Kingdom that has been in produc- 
tion for nearly 60 years. Each issue of New Scientist in 
its current format is about 50 pages in length, only a very 
small part of which is taken up by advertising. This makes 
scanning an issue for topics of interest by page-flipping 
very efficient. 

The periodical has approximately 100 different topics in 
each issue, ranging from single paragraphs to multi-page, 
in-depth articles. All the sciences are represented, with 
an adequate amount specifically related to healthcare or 
the life sciences. The short-length items dominate, but a 
scan of these provides the reader with a vast assortment 
of new and useful information rather quickly. The longest 
multi-page articles tend to be mostly tutorial in nature, 
which is useful for topics that are unfamiliar or superfi- 
cially understood by the reader. 

New Scientist frequently presents science findings in 
relationship to social issues and policy. As an example, 
a recent article addressed the U.S. military’s reversal of 
its policy banning women from combat jobs. 12 The article 
explored the role of science in setting specific physical 
standards for combat positions, in developing technolo- 
gies to reduce physical stress on both sexes, and in better 
understanding experiences that aid soldiers in coping with 
combat. While this particular article is certainly good 
information for anyone having an interest in the military’s 
Readiness mission, the communication of science within 
a social context gives this publication and its content 
wider audience relevance. 

In addition, the editorial page and opinion items often 
contain thoughtful, and in some cases, instructive 
approaches in developing and refining a point with the 
intent to support sound decision-making - a hallmark of 
the most valued analysts. The inside back-cover page is 
dedicated to inviting the readership to pose questions on 
something they have observed and to respond with their 
theories on answers to submitted questions. This forum 
is useful to cultivate the important analytic skills of 
speculation and proposed explanation, rather than simply 
reporting on the observed. 

Print, web and e-magazine subscriptions are available. 
Select pieces of full content from each issue, as well as 
preview content, are freely browsable at their website at 
http://www.newscientist.com/ . 


IN THE NEXT ISSUE 


The next issue of Healthcare Analytics in Navy 
Medicine will focus on the characteristics of critical 
thinking, and their application in the analytic process. 
Specific aspects of critical thinking will be explored, 
and resources to improve sound critical thinking will 
be presented. 
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